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Locating IEEE 802.21 Mobility Services Using DNS 
Abstract 
This document defines application service tags that allow service 


location without relying on rigid domain naming conventions, and DNS 
procedures for discovering servers that provide IEEE 802.21-defined 


Mobility Services. Such Mobility Services are used to assist a 
Mobile Node (MN) supporting IEEE 802.21, in handover preparation 
(network discovery) and handover decision (network selection). The 


services addressed by this document are the Media Independent 
Handover Services defined in IEEE 802.21. 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 
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1. Introduction 


TEEE 802.21 [IEEE802.21] defines three distinct service types to 
facilitate link-layer handovers across heterogeneous technologies: 


a) MIH Information Service (MIHIS) 
IS provide a unified framework to the higher-layer entities across 
the heterogeneous network environment to facilitate discovery and 
selection of multiple types of networks existing within a 
geographical area, with the objective to help the higher-layer 
mobility protocols to acquire a global view of the heterogeneous 
networks and perform seamless handover across these networks. 


b) MIH Event Service (MIHES) 
Events may indicate changes in state and transmission behavior of 
the physical, data link and logical link layers, or predict state 
changes of these layers. The Event Services may also be used to 
indicate management actions or command status on the part of the 
network or some management entity. 


c) MIH Command Service (MIHCS) 
The command service enables higher layers to control the physical, 
data link, and logical link layers. The higher layers may control 
the reconfiguration or selection of an appropriate link through a 
set of handover commands. 


In IEEE terminology, these services are called Media Independent 
Handover (MIH) services. While these services may be co-located, the 
different pattern and type of information they provide do not 
necessitate the co-location. 
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"Service Management" service messages, i.e., MIH registration, MIH 
capability discovery and MIH event subscription messages, are 
considered as MIHES and MIHCS when transporting MIH messages over L3 
transport. 


A Mobile Node (MN) may make use of any of these MIH service types 
separately or any combination of them. 


It is anticipated that a Mobility Server will not necessarily host 
all three of these MIH services together, thus there is a need to 
discover the MIH service types separately. 


This document defines a number of application service tags that allow 
service location without relying on rigid domain naming conventions. 


1.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

1.2. Terminology 
Mobility Services: composed of a set of different services provided 


by the network to mobile nodes to facilitate handover preparation and 
handover decision, as described in [IEEE802.21] and [RFC5164]. 


| 


Mobility Server: a network node providing IEEE 802.21 Mobility 
Services. 


MIH: Media Independent Handover, as defined in [IEEE802.21]. 
Application service: is a generic term for some type of application, 
independent of the protocol that may be used to offer it. Each 


application service will be associated with an IANA-registered tag. 


Application protocol: is used to implement the application service. 
These are also associated with IANA-registered tags. 


Home domain: the DNS suffix of the operator with which the Mobile 
Node has a subscription service. The suffix is usually stored in the 
Mobile Node as part of the subscription. 

2. Discovering a Mobility Server 
The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to 


implement lazy binding of strings to data, in order to support 
dynamically configured delegation systems. The DDDS functions by 
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mapping some unique string to data stored within a DDDS database by 
iteratively applying string transformation rules until a terminal 
condition is reached. When DDDS uses DNS as a distributed database 
of rules, these rules are encoded using the Naming Authority Pointer 
(NAPTR) Resource Record (RR). One of these rules is the First Well 
Known Rule, which says where the process starts. 


In current specifications, the First Well Known Rule in a DDDS 
application [RFC3403] is assumed to be fixed, i.e., the domain in the 
tree where the lookups are to be routed to, is known. This document 
proposes the input to the First Well Known Rule to be dynamic, based 
on the search path the resolver discovers or is configured with. 


The search path of the resolver can either be pre-configured, 
discovered using DHCP, or learned from a previous MIH Information 
Services (IS) query [IEEE802.21] as described in [RFC5677]. 


When the MN needs to discover Mobility Services in its home domain, 
the input to the First Well Known Rule MUST be the MN’s home domain, 
which is assumed to be pre-configured in the MN. 


When the MN needs to discover Mobility Services in a local (visited) 
domain, it SHOULD use DHCP as described in [RFC5678] to discover the 
IP address of the server hosting the desired service, and contact it 
directly. In some instances, the discovery may result in a per 
protocol/application list of domain names that are then used as 
starting points for the subsequent NAPTR lookups. If neither the IP 
address or domain name can be discovered with the above procedure, 
the MN MAY request a domain search list, as described in [RFC3397] 
and [RFC3646], and use it as input to the DDDS application. 


The MN may also have a list of cached domain names of Service 
Providers, learned from a previous MIH Information Services (IS) 
query [IEEE802.21]. If the cache entries have not expired, they can 
be used as input to the DDDS application. 


When the MN does not find valid domain names using the procedures 
above, it MUST stop any attempt to discover MIH services. 


The dynamic rule described above SHOULD NOT be used for discovering 
services other than MIH services described in this document, unless 
stated otherwise by a future specification. 


The procedures defined here result in an IP address, port, and 
transport protocol where the MN can contact the Mobility Server that 
hosts the service the MN is looking for. 


Bajko Standards Track [Page 4] 


RFC 5679 Locating Mobility Services Using DNS December 2009 


2.1. Selecting a Mobility Service 


The MN should know the characteristics of the Mobility Services 
defined in [IEEE802.21], and based on that, it should be able to 
select the service it wants to use to facilitate its handover. The 
services it can choose from are: 

— Information Services (MIHIS) 

—- Event Services (MIHES) 

-—- Command Services (MIHCS) 


The service identifiers for the services are "MIHIS", "MIHES", and 
"MTHCS", respectively. The server supporting any of the above 
services MUST support at least UDP and TCP as transport, as described 
in [RFC5677]. SCTP and other transport protocols MAY also be 
supported. 


2.2. Selecting the Transport Protocol 


After the desired service has been chosen, the client selects the 
transport protocol it prefers to use. Note that transport selection 
may impact the handover performance. 


The services relevant for the task of transport protocol selection 
are those with NAPTR service fields with values "ID+M2X", where ID is 
the service identifier defined in the previous section, and X is a 
letter that corresponds to a transport protocol supported by the 
domain. This specification defines M2U for UDP, M2T for TCP and M2S 
for SCTP. This document also establishes an IANA registry for 
mappings of NAPTR service name to transport protocol. 


These NAPTR [RFC3403] records provide a mapping from a domain to the 
SRV [RFC2782] record for contacting a server with the specific 
transport protocol in the NAPTR services field. The resource record 
MUST contain an empty regular expression and a replacement value, 
which indicates the domain name where the SRV record for that 
particular transport protocol can be found. If the server supports 
multiple transport protocols, there will be multiple NAPTR records, 
each with a different service value. As per [RFC3403], the client 
discards any records whose services fields are not applicable. 


The MN MUST discard any service fields that identify a resolution 
service whose value is not "M2X", for values of X that indicate 
transport protocols supported by the client. The NAPTR processing as 
described in RFC 3403 will result in the discovery of the most 
preferred transport protocol of the server that is supported by the 
client, as well as an SRV record for the server. 
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As an example, consider a client that wishes to find MIHIS service in 
the example.com domain. The client performs a NAPTR query for that 
domain, and the following NAPTR records are returned: 


Order Pref Flags Service Regexp Replacement 
IN NAPTR 50 50 "s"  "MIHTIS+M2T" "" _MTHIS._tcp.example.com 
IN NAPTR 90 50 "s" "MIHTS+M2U" "" _MTHIS._udp.example.com 


This indicates that the domain does have a server providing MIHIS 
services over TCP and UDP, in that order of preference. Since the 
client supports TCP and UDP, TCP will be used, targeted to a host 
determined by an SRV lookup of _MIHIS._tcp.example.com. That lookup 
would return: 


ra Priority Weight Port Target 
IN SRV 0 I XXXX serverl.example.com 
IN SRV 0 2 XXXX server2.example.com 


where XXXX represents the port number at which the service is 
reachable. 


If no NAPTR records are found, the client constructs SRV queries for 
those transport protocols it supports, and does a query for each. 
Queries are done using the service identifier "_MIHIS" for the MIH 
Information Service, "_MIHES" for the MIH Event Service and "_MIHCS" 
for the MIH Command Service. A particular transport is supported if 
the query is successful. The client MAY use any transport protocol 
it desires that is supported by the server. 


Note that the regexp field in the NAPTR example above is empty. The 
regexp field MUST NOT be used when discovering MIH services, as its 
usage can be complex and error prone. Also, the discovery of the MIH 
services does not require the flexibility provided by this field over 
a static target present in the TARGET field. 


If the client is already configured with the information about which 
transport protocol is used for a mobility service in a particular 
domain, it can directly perform an SRV query for that specific 
transport using the service identifier of the Mobility Service. For 
example, if the client knows that it should be using TCP for MIHIS 
service, it can perform a SRV query directly for 
_MIHIS._tcp.example.com. 


2.3. Determining the IP Address and Port 
Once the server providing the desired service and the transport 


protocol has been determined, the next step is to determine the IP 
address and port. 
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The response to the SRV DNS query contains the port number in the 
Port field of the SRV RDATA. 


According to the specification of SRV RRs in [RFC2782], the TARGET 
field is a fully qualified domain name (FQDN) that MUST have one or 
more address records; the FQDN must not be an alias, i.e., there MUST 
NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 
already has reported a sufficient number of these address records in 
the Additional Data section of the DNS response (as recommended by 
[RFC2782]), the MN needs to perform A and/or AAAA record lookup(s) of 
the domain name, as appropriate. The result will be a list of IP 
addresses, each of which can be contacted using the transport 
protocol determined previously. 


3. IANA Considerations 
The usage of NAPTR records described here requires well-known values 
for the service fields for each transport supported by Mobility 
Services. The table of mappings from service field values to 
transport protocols is to be maintained by IANA. 


The registration in the RFC MUST include the following information: 


Service Field: The service field being registered. 


Protocol: The specific transport protocol associated with that 
service field. This MUST include the name and acronym for the 
protocol, along with reference to a document that describes the 
transport protocol. 


Name and Contact Information: The name, address, email address, 
and telephone number for the person performing the registration. 


The following values have been placed into the registry: 


Service Fields Protocol 
MIHIS+M2T TCP 
MIHIS+M2U UDP 
MIHIS+M2S SCTP 
MIHES+M2T TCP 
MIHES+M2U UDP 
MIHES+M2S SCTP 
MIHCS+M2T TCP 
MIHCS+M2U UDP 
MIHCS+M2S SCTP 


New Service Fields are to be added via Standards Action as defined in 
[RFC5226]. 
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New entries to the table that specify additional transport protocols 
for the existing Service Fields may similarly be registered by IANA 
through Standards Action [RFC5226]. 


IANA is also requested to register MIHIS, MIHES, MIHCS as service 
names in the Protocol and Service Names registry. 


4. Security Considerations 


A list of known threats to services using DNS is documented in 
[RFC3833]. For most of those identified threats, the DNS Security 
Extensions [RFC4033] does provide protection. It is therefore 
recommended to consider the usage of DNSSEC [RFC4033] and the aspects 
of DNSSEC Operational Practices [RFC4641] when deploying IEEE 802.21 
Mobility Services. 


In deployments where DNSSEC usage is not feasible, measures should be 
taken to protect against forged DNS responses and cache poisoning as 
much as possible. Efforts in this direction are documented in 
[RFC5452]. 


Where inputs to the procedure described in this document are fed via 
DHCP, DHCP vulnerabilities can also cause issues. For instance, the 
inability to authenticate DHCP discovery results may lead to the 
mobility service results also being incorrect, even if the DNS 
process was secured. 
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